The field of the invention is automated systems and more specifically systems wherein a processor performs a program to control an automated set of resources and, when resource operation is halted, provides guidance regarding how to place the resources in a condition that allows the process to be restarted. The invention also includes a method by which the processor learns how to provide guidance to a system operator.
A typical automated manufacturing system includes a processor or programmable logic controller (PLC), a plurality of automated resources (e.g., machines such as mills, drills, transfer lines, clamps, position sensors, proximity sensors, switches, sprayers, robotic welding arms, etc.) and, in many cases, one or more human-machine interfaces (HMIs) (e.g., display screens and some type of input devices). The resources are configured to perform a process on items or assemblies (e.g., work products) being manufactured, treated, sorted, etc., and are linked to the PLC via I/O lines so that the PLC can command the resources to perform the various process steps and can monitor progress of the manufacturing process. The interface is usually linked to the PLC so that the PLC can provide information to a system operator regarding current and/or historical status of the process and warning indications when unusual operating characteristics occur. In many cases the interface also enables the operator to interact with and control the system by stopping the process, altering process operations and manually manipulating the resources when necessary.
A typical process performed by a PLC and associated resources includes several sequences that are, in general, performed sequentially, with one sequence followed by another which is in turn followed by another sequence, and so on. Each sequence typically includes a plurality of cells.
As indicated above, during performance of a process the PLC runs a program and generates commands provided to the resources to cause the resources to perform their parts of the overall process and receives feedback regarding the current operating characteristics (ROCs) of the resources. Prior to transitioning from one of the cells to the next, the PLC is programmed to determine that all of the resources are in a transition state (I.e., that the ROCs are all in a required state) that is required to commence the next cell. For instance, where a part has to be present in a specific position for a cell to commence, one of the ROCs that has to be met prior to performing the cell may be for a proximity sensor to indicate that a part is sensed at a station associated with the specific position. As another instance, prior to commencing another cell, one of the ROCs that may have to be met may be that each of four clamps be in an extended state so that a work item proximate thereto is completely secured. Hereinafter, unless indicated otherwise, the phrase “required ROCs” will be used to refer to resource characteristics that are required for a cell to commence.
During system operation, if required ROCs do not exist to transition to a next cell, the PLC is programmed to stop the process and indicate, via the interface, that an error has occurred. Thus, for instance, in the example above where required ROCs indicate that each of four clamps have to be in an extended state prior to transitioning to a next cell, if the first and second clamps are extended but the third and fourth clamps are not extended, the PLC will stop the process and provide messages to a system operator indicating that the third and fourth clamps are not extended.
To track required ROCs and current states, interlock software is usually run in the background of the process program software to record resource status changes that occur under control of the program in an interlock table, to routinely identify current ROCs, to compare current ROCs to resource status in the table and to indicate when a resource has changed state independent of the program control. Where a resource status changes outside the program control the associated process is typically halted and an error or warning message is generated.
After observing the warning message, an operator examines the resources to determine the cause of the error. In many cases an operator may have to manually manipulate at least a sub-set of the resources in order to identify the cause of the error and/or to eliminate the cause of the error. Once the cause of the error has been alleviated, the operator can restart the process. In order to restart the process at a specific sequence cell, all of the required ROCs for the preceding cell have to exist.
To help a system operator restart a halted process three similar yet independent features have been developed including a halt cell error stack feature, a manual step restart (MSR) feature and a resequencing feature. The halt cell error stack feature is facilitated by the PLC wherein the PLC identifies required ROCs to restart a halted process at the halt cell, identifies current ROCs, compares the current and required ROCs to identify differences and then generates an error stack via the interface thereby indicating resources that are not in states required to restart at the halt cell. To this end, manual resource movements often result in resources that are out of positions or states required to restart at the halt cell. The stack operates as a guide to indicate steps that should be manually performed to place the resources in the required states to restart. As the resources are manipulated, the PLC determines that stack errors have been eliminated and removes the stack errors from the stack. Once all the stack errors have been eliminated the operator can restart the process at the halt cell.
The MSR feature enables an operator to select virtually any sequence cell in an automatic sequence at which to restart a halted sequence and identifies required ROCs for restarting at the selected cell that do not currently exist. To this end, in at least some cases, after the cause of an error has been eliminated through manual changes in resource states, an operator may choose to manually step through other process steps or even entire sequence cells to manually check for proper operation of station resources. Here, because resource states are manually changed and in fact portions of a sequence may have been manually performed, it may make sense and indeed be optimal to restart a sequence at a cell subsequent to the halt cell. When a cell at which to restart is selected, pursuant to the MSR feature, the PLC identifies required ROCs associated with the selected cell along with current ROCs, compares the required and current ROCs, generates an error stack indicating differences between the required and current ROCs and displays the error stack as a guide for the operator to manipulate the resources required to restart.
The resequencing feature enables an operator to identify any sequence cells that have required ROCs that match current ROCs. In this regard, it may be that during manipulations to eliminate the cause of an error the operator manually stepped the resources completely through one or more of the sequence cells and that therefore the required ROCs for a cell subsequent to the halt cell match current ROCs. In this case restart can be expedited by restarting at the subsequent cell associated with required ROCs that match the current ROCs.
Parallel and conditional processing are two general exceptions to the sequential processing scheme where, as the labels imply, parallel processing includes executing several cells in parallel and conditional processing includes executing at least a sub-set of cells only when certain conditions have occurred. Most industry members have approached parallel and conditional processing by simulating the effects thereof via sequential cell execution. Parallel and conditional simulating programs employ sequential processing and rely on other software to, in effect, simulate parallel and conditional processing. Here, with respect to parallel processing, while a PLC cell may commence parallel processing and other sequential cells may track parallel processing, other processors in addition to the PLC are typically employed to perform the parallel processes. For instance, where four robots are to perform parallel processes, each robot may be provided with its own processor and program and the PLC program may include a cell that starts the parallel robot processes and a subsequent sequential cell that determines if the robot processes have been completed. With respect to conditional processing, these programs have typically included several separate sequences where the PLC or some other processor selects a sequence based on conditional factors as opposed to providing decision or conditional cells within the PLC program itself.
Known systems that simulate parallel and conditional processing include a generally non-graphic interface type (hereinafter “the non-graphic interface”) that includes some non-graphic way (e.g., a field or on-screen box) to indicate a number corresponding to a cell (i.e., a cell number) at which to restart a halted process and that provides an error stack or error list to guide an operator during a restart process. Here, each programming cell is labeled with a cell number. During normal operation of a process, the PLC tracks the current or active cell number and indicates that number via the interface. When the process stops, the PLC displays the halt number for the operator to observe along with a way to select a different cell number for restart.
Systems that only simulate parallel and conditional processing have several shortcomings. First, because these systems rely on processors and processes in addition to the PLC and the processes directly performed by the PLC, they are relatively more complex to program and overall system coordination is generally more complex. Second, most systems of this type only support a limited number of possible programming branches and hence cannot be easily used for certain application types.
One solution to the problems associated with systems that simulate parallel and conditional cell execution has been to develop programs and related systems that support true parallel and conditional programming. Programs that support true parallel and conditional processing include sequences that actually include parallel cells and decision or conditional cells that can branch off to other sub-sets of cells to perform different functions and sub-processes based on various conditions and factors. True parallel and conditional processing is much more flexible than simulated parallel and conditional processing and simplifies the programming task appreciably.
To interface with PLCs that support true parallel and conditional programming a graphical interface has been developed. In addition to including an error stack as a guide to restarting a halted process, an exemplary graphical interface graphically provides a flow chart that illustrates the sequence cells linked by lines that signify sequence flow from one cell to the next or to several parallel cells or sequence branches where decision blocks occur. In this case, when a sequence halts at a cell, a flow chart including the halt cell as well as cells before and after the halt cell is provided via a display and the halt cell is typically visually distinguished (e.g., highlighted) in some fashion on the display screen for viewing by an operator.
While systems that support true parallel and conditional processing and that include graphical interfaces for communicating with operators and for facilitating restart processes seem simple enough, unfortunately even these systems have shortcomings and are complicated in a number of ways. First, most PLCs have to support many different applications and many of those applications are critical to proper run time operation of the resources. Whenever possible it is desirable to reduce the percentage of PLC resources dedicated to non-critical tasks and applications. In the case of error messaging and restart processes, messaging and restart processes are generally considered non-critical. Known systems have used the PLC to support all messaging and restart processes which disadvantageously ties up PLC capabilities.
Second, while true parallel and conditional processing has many advantages, known graphical interfaces have not been successfully developed to support the MSR and the resequencing features where true parallel and conditional cell execution occurs. One impediment to supporting the MSR and resequencing features where true parallel and conditional cell execution occurs has been identifying required ROCs for restarting within a parallel section of a sequence. To this end, assume a parallel section of a sequence including seven branches where each branch includes seven sequential cells. With respect to the MSR feature, while known graphical interfaces can highlight a set of halt cells including one cell in each branch for a total of seven cells, the interfaces provide no way to alter the cell sub-set selected for restarting purposes. Instead, when the process halts, the interface only supports restarting at the halt cells. With respect to the resequencing feature, in the context of a parallel section of a sequence, the processing requirement for identifying the different combinations of required ROCs for restarting a process at least cell and at each sub-set of cells in parallel branches of a sequence has been considered too great to be support via the PLC.
Third, there are complexities involved with identifying required ROCs for restart at cells where true conditional cell execution is included in a process. To this end, in the above example where a user wishes to restart the process at a cell subsequent to a halt cell, when the operator selects the subsequent cell for restart, in order to identify the required ROCs associated with the selected cell, the PLC was programmed to virtually run the halted sequence to identify the required ROCs for restarting at the selected cell. This process usually required the PLC to start the virtual sequence in a known state by carrying out a virtual execution of a “home sequence” (i.e., a sequence that places the resources in a known state) before beginning virtual execution of the automatic sequence and continuing execution up to the point of the selected restart cell.
Unfortunately, in at least some cases virtual determination of required ROCs is severely complicated when a program includes multiple possible processing branches (i.e., one or more nested decision cells) as the virtual determination has to select which of two or more branches to assume while working its way through the process from the home sequence to the selected cell. The complexity of the decision regarding which of two or more processing branches to assume is exacerbated in the case of relatively newer control processes where branch decisions can be made on the basis of many different factors including, among others, status of assemblies both locally located and located at remote stations, simple Boolean expressions, logical mathematical operations and other factors that cannot be automatically simulated during the virtual cell execution. For instance, in the case of a decision cell where first and second branches are performed when first and second conditions occur at a remote station, respectively, if neither the first nor the second conditions exist at the remote station when the decision cell is virtually performed, the virtual processing to identify the required restart ROCs will fail to execute past the decision cell and the attempt to generate an error stack will fail.
Thus, it would be advantageous to have a system wherein non-critical restarting processes are supported at least in part by other than the PLC, where both parallel processing and an MSR feature are supported in a system that enables true parallel and conditional cell execution and where decision cell errors that could occur during virtual cell execution due to insufficient knowledge about factors associated with the decision cells are avoided.